Hash based device configuration management

ABSTRACT

According to an example, with respect to hash based device configuration management, a device configuration status and a device configuration hash value associated with a configuration file for a device may be ascertained. Based on a determination that the device configuration hash value matches an application configuration hash value, an application configuration status for the device may be modified to correspond to the device configuration status. If there is no match, a determination may be made as to whether the device has permission to locally modify the configuration for the device, and if not, a configuration file may be sent to the device to modify the configuration for the device. If the device has permission, the configuration file that is associated with the device configuration hash value may be requested, and a configuration record associated with the device may be updated based on the requested configuration file.

BACKGROUND

A device may include a configuration that specifies various attributesof the device. For example, for a device that includes a sensor, aconfiguration may include a frequency at which the sensor is to read ortransmit data. According to another example, the sensor may include atype of data that may be read or transmitted. A configuration may bedescribed to include any operational attribute of a device. A device maybe one of a plurality of devices that may be utilized to collect orprovide information. In this regard, the plurality of devices may bepart of an Internet of Things (IoT), e.g., the plurality of devices mayform a network of physical devices. The physical devices may include,for example, automobiles, home appliances and other such devices. Thedevices may be embedded with features such as sensors, electronics,executable software code, and actuators. Further, the devices mayinclude connectivity that provides the ability to interconnect andexchange data.

BRIEF DESCRIPTION OF DRAWINGS

Features of the present disclosure are illustrated by way of examplesshown in the following figures. In the following figures, like numeralsindicate like elements, in which

FIG. 1 illustrates an architecture of a hash based device configurationmanagement system, according to an example of the present disclosure;

FIG. 2 illustrates further details of the architecture of the hash baseddevice configuration management system of FIG. 1, according to anexample of the present disclosure;

FIG. 3 illustrates further details of the architecture of the hash baseddevice configuration management system of FIG. 1, including a globalconfiguration library and a device-to-configuration library, accordingto an example of the present disclosure;

FIG. 4 illustrates a device configuration request flow to illustrateoperation of the hash based device configuration management system ofFIG. 1, according to an example of the present disclosure;

FIG. 5 illustrates a third party request flow to illustrate operation ofthe hash based device configuration management system of FIG. 1,according to an example of the present disclosure;

FIG. 6 illustrates a third party application request flow to illustrateoperation of the hash based device configuration management system ofFIG. 1, according to an example of the present disclosure;

FIG. 7 illustrates a device originated flow to illustrate operation ofthe hash based device configuration management system of FIG. 1,according to an example of the present disclosure;

FIG. 8 illustrates a command queuing sub-process flow to illustrateoperation of the hash based device configuration management system ofFIG. 1, according to an example of the present disclosure;

FIG. 9 illustrates a global file library-check sub-process flow toillustrate operation of the hash based device configuration managementsystem of FIG. 1, according to an example of the present disclosure;

FIG. 10 illustrates a device initiated delete flow to illustrateoperation of the hash based device configuration management system ofFIG. 1, according to an example of the present disclosure;

FIG. 11 illustrates a block diagram for hash based device configurationmanagement, according to an example of the present disclosure;

FIG. 12 illustrates a flowchart of a method for implementing a hashbased device configuration management, according to an example of thepresent disclosure; and

FIG. 13 illustrates a further block diagram for hash based deviceconfiguration management, according to an example of the presentdisclosure.

DETAILED DESCRIPTION

For simplicity and illustrative purposes, the present disclosure isdescribed by referring mainly to examples thereof. In the followingdescription, numerous specific details are set forth in order to providea thorough understanding of the present disclosure. It will be readilyapparent however, that the present disclosure may be practiced withoutlimitation to these specific details. In other instances, some methodsand structures have not been described in detail so as not tounnecessarily obscure the present disclosure.

Throughout the present disclosure, the terms “a” and “an” are intendedto denote at least one of a particular element. As used herein, the term“includes” means includes but not limited to, the term “including” meansincluding but not limited to. The term “based on” means based at leastin part on.

Hash based device configuration management systems, methods forimplementing a hash based device configuration management, andnon-transitory computer readable media having stored thereon machinereadable instructions for hash based device configuration management aredisclosed herein. The systems, methods, and non-transitory computerreadable media disclosed herein provide for the management ofconfigurations for a population of Internet of Things (IoT) devices. Inthis regard, the managed configurations may be referenced by using, forexample, a Secure Hash Algorithm 1 (SHA-1) hash of the configurationfile. A syncing mechanism may be utilized to update a configuration fora connected device if it is determined that the configuration has beencorrupted or erased.

With respect to configuration management for devices, industries mayutilize hundreds of thousands, and often millions of IoT devices.Management of such devices may be technically challenging in that eachdevice may include a unique configuration. For example, for devices thatinclude sensors disposed at different locations, each sensor may includea unique configuration corresponding to a location. For example, eachsensor may include a unique data transmission rate and/or timecorresponding to a location. Alternatively, even if the devices areclustered into fleets of devices, such fleets may include uniqueconfigurations that may need to be uniquely managed. It may also betechnically challenging to manage configurations of devices as themanagement may depend on factors such as wireless coverage strengthassociated with each device, a power state of each device, whether adevice has been physically tampered with, etc. In this regard, when suchlarge volumes of devices are to be managed, such factors may addtechnical complexities to the management of such devices. For example,it is technically challenging to efficiently manage all of the differentconfigurations of the devices considering all of the potentialvariables.

In order to address at least the aforementioned technical challengeswith respect to configuration management of devices, such as IoTdevices, the systems, methods, and non-transitory computer readablemedia disclosed herein provide a single library with a single copy ofeach unique device configuration to manage a plurality of IoT devices.The systems, methods, and non-transitory computer readable mediadisclosed herein provide for the secure abstraction of a configurationfile itself from the configuration management process, until theconfiguration file is needed to be sent to a device. The systems,methods, and non-transitory computer readable media disclosed hereinprovide for deployment of a single configuration across a fleet of IoTdevices. Further, the systems, methods, and non-transitory computerreadable media disclosed herein provide for reduction intelecommunications bandwidth utilization by limiting scenarios in whicha full configuration is sent to a device or is received from a device.For example, instead of the need to send a full configuration file to adevice, or to receive a full configuration file from a device, atechnical analysis may be performed to determine whether the fullconfiguration file needs to be sent to or received from a device. Yetfurther, aspects such as wireless coverage strength, power state of adevice, etc., may be analyzed to determine whether a configuration fileis to be sent to a device. The systems, methods, and non-transitorycomputer readable media disclosed herein may also be implemented toreplace corrupt configurations on a device, to re-synchronize aconfiguration with a device in the event of a technical or connectivityerror, and to maintain a configuration status of all devices. Yetfurther, the systems, methods, and non-transitory computer readablemedia disclosed herein provide for automation (e.g., without humanintervention) of the processes by which the configurations are managed.This automation allows for larger populations of IoT devices to be usedwith an increasing amount of variance. With the large number of IoTdevices, corrupted configurations and communication failures may belikely. In this regard, the systems, methods, and non-transitorycomputer readable media disclosed herein provide for automatedrestoration and/or resetting of the corrupt and/or failedconfigurations, and may do so in a manner that addresses the technicalchallenges of transmitting an entire configuration to the devices whensuch may not be needed, conserving network bandwidth (and in particularcases, cellular network bandwidth).

According to examples disclosed herein, the systems, methods, andnon-transitory computer readable media disclosed herein may provide fordevice-level configuration management in that a device may retrieveconfiguration files from the system, and apply the configurations. Thedevice may send a confirmation message to the system with status ofconfiguration, along with a device configuration hash value (e.g., aSHA-1 value) of the configuration. Further, the device may not send theconfiguration file itself or any identifiable information other thanconfiguration's hash value. The use of hash values and more particularlyhashes in the systems, methods, and non-transitory computer readablemedia disclosed herein addresses another technical problem—networksecurity. The use of hashes allows the systems, methods, andnon-transitory computer readable media disclosed herein to detectwhether a configuration may have been compromised.

According to examples disclosed herein, the systems, methods, andnon-transitory computer readable media disclosed herein may provide forapplication level syncing in that an application (e.g., the system) mayaccept the configuration status and hash from the device. Theapplication may accept the configuration status and hash value on recordfor the device. If the values match, no action may be taken andapplication's status for that device configuration may be updated. Ifthe values do not match and the device does not have permission toupdate the configuration locally, the configuration file may be resentto the device. If the values do not match and the device does havepermission to update the configuration locally, the application mayupdate its records for that device and request the file itself from thedevice.

According to examples disclosed herein, the systems, methods, andnon-transitory computer readable media disclosed herein may provide aglobal configuration library that includes configuration file type (ifneeded), and a hash (e.g., a SHA-1) for each device. Further, allrecords in the global configuration library may map to the application'sfile system, where the files themselves are stored. Adevice-to-configuration library may store all IoT devices associatedwith the application (e.g., the system), and a reference to the globalconfiguration library for each configuration file on the device.

According to examples disclosed herein, if a third party application isto send a configuration to a device, the third party application maypass the hash value of the configuration. The systems, methods, andnon-transitory computer readable media disclosed herein may provide forthe retrieval of the configuration file from the file system and sendthe retrieved configuration file to the device. Further, notificationmessages may be sent to third party applications as needed, when theconfiguration status is updated from the device.

In some examples, elements of the hash based device configurationmanagement system may be machine readable instructions stored on anon-transitory computer readable medium. In this regard, the hash baseddevice configuration management system may include or be anon-transitory computer readable medium. In some examples, the elementsof the hash based device configuration management system may be hardwareor a combination of machine readable instructions and hardware.

FIG. 1 illustrates an architecture of a hash based device configurationmanagement system 100 (hereinafter “system 100”), according to anexample of the present disclosure.

Referring to FIG. 1, the system 100 may include a device configurationanalyzer 102 that is executed by at least one hardware processor (e.g.,the hardware processor 1102 of FIG. 11, and/or the hardware processor1304 of FIG. 13) to ascertain, over a network 104, a deviceconfiguration status 106 of a device 108 of a plurality of devices108(a)-108(n), and a device configuration hash value 110 associated witha configuration file 112 for the device 108.

According to examples disclosed herein, the device 108 may include anInternet of Things (IoT) device. Similarly, the devices 108(a)-108(n)may include IoT devices.

According to examples disclosed herein, in FIG. 1, the network 104 isdisclosed between the system 100 and the devices 108(a)-108(n) forillustrative purposes. In this regard, the network 104 may be expandedor reduced to interconnect other devices, entities (e.g., applications),etc.

The device configuration analyzer 102 may determine whether the deviceconfiguration hash value 110 matches an application configuration hashvalue 114.

A device configuration status controller 116 that is executed by the atleast one hardware processor (e.g., the hardware processor 1102 of FIG.11, and/or the hardware processor 1304 of FIG. 13) may modify, based ona determination that the device configuration hash value 110 matches theapplication configuration hash value 114, an application configurationstatus 118 for the device 108 to correspond to the device configurationstatus 106 of the device 108.

According to examples disclosed herein, the device configuration hashvalue 110 may be a Secure Hash Algorithm 1 (i.e., SHA-1) value.Similarly, the application configuration hash value 114 may be SHA-1. Ofcourse, it should be understood that other hash algorithms could beemployed, such as Secure Hash Algorithm 2 (SHA-2) or BLAKE2.

A device configuration controller 120 that is executed by the at leastone hardware processor (e.g., the hardware processor 1102 of FIG. 11,and/or the hardware processor 1304 of FIG. 13) may determine, based on adetermination that the device configuration hash value 110 does notmatch the application configuration hash value 114, whether the device108 has permission to locally modify the configuration for the device108.

Based on a determination that the device 108 does not have permission tolocally modify the configuration for the device 108, the deviceconfiguration controller 120 may send, over the network 104, aconfiguration file to the device 108 to modify, based on the sentconfiguration file, the configuration for the device 108.

Based on a determination that the device 108 has permission to locallymodify the configuration for the device 108, the device configurationcontroller 120 may request, over the network 104, the configuration file(e.g., the configuration file 112 or another configuration file) that isassociated with the device configuration hash value 110 and is used bythe device 108 to modify the configuration for the device 108. Further,the device configuration controller 120 may update, upon receipt, overthe network 104, of the requested configuration file, a configurationrecord 122 associated with the device 108 based on the requestedconfiguration file.

According to examples disclosed herein, further to the sending, over thenetwork 104, the configuration file to the device 108 to modify, basedon the sent configuration file, the configuration for the device 108,the device configuration analyzer 102 may ascertain, from the device 108and over the network 104, the device configuration status 106 of thedevice 108. That is, the device configuration analyzer 102 may check theupdated status of the device 108. In this regard, the deviceconfiguration analyzer 102 may ascertain the device configuration hashvalue 110 associated with the configuration file that is used to modifythe configuration for the device 108. The device configuration analyzer102 may determine whether the device configuration hash value 110associated with the configuration file that is used to modify theconfiguration for the device 108 matches the application configurationhash value 114. Further processing with respect to the deviceconfiguration analyzer 102 may proceed as described above.

According to examples disclosed herein, the device configurationanalyzer 102 may determine whether the device configuration hash value110 matches the application configuration hash value 114 by accessing,over the network 104, a global configuration library 124 that storesapplication configuration hash values including the applicationconfiguration hash value 114. The application configuration hash valuesmay be mapped to associated configuration files. The deviceconfiguration analyzer 102 may access, over the network 104, adevice-to-configuration library 126 that stores a reference to theglobal configuration library 124 for each configuration file on a device108. The device configuration analyzer 102 may ascertain, based on theaccess to the global configuration library 124 and thedevice-to-configuration library 126, the application configuration hashvalue 114 associated with the device 108 for which the deviceconfiguration hash value 110 is ascertained.

According to examples disclosed herein, the device configurationcontroller 120 may ascertain, over the network 104, a request (e.g.,from another application, or an entity generally) to update theconfiguration for the device 108. The device configuration controller120 may ascertain, over the network 104, another device configurationhash value associated with the request to update the configuration forthe device 108. The device configuration controller 120 may retrieve,over the network 104, a configuration file (e.g., from an applicationfile system 128 that stores configuration files including theconfiguration file 112) associated with the another device configurationhash value. The device configuration controller 120 may send, to thedevice 108 and over the network 104, the retrieved configuration fileassociated with the another device configuration hash value to updatethe configuration for the device 108.

According to examples disclosed herein, the device configurationanalyzer 102 may notify, over the network 104, an entity (e.g., theother application) associated with the request to update theconfiguration for the device 108, the device configuration status 106 ofthe device 108 upon completion of the update, based on the retrievedconfiguration file associated with the another device configuration hashvalue, of the configuration for the device 108.

According to examples disclosed herein, the device configurationanalyzer 102 may receive, over the network 104, a request from an entity(e.g., another application) for the configuration file (e.g., theconfiguration file 112, or another configuration file) that is used bythe device 108. The device configuration analyzer 102 may determine,based on the received request from the entity for the configuration filethat is used by the device 108, whether the configuration file that isused by the device 108 is known (e.g., the configuration file 112) orunknown (e.g., another configuration file). Based on a determinationthat the configuration file that is used by the device 108 is known, thedevice configuration analyzer 102 may generate, for the entity, aresponse that includes an indication of the configuration file that isused by the device 108.

According to examples disclosed herein, the device configurationanalyzer 102 may ascertain, based on a determination that theconfiguration file that is used by the device 108 is unknown, from thedevice 108, the configuration file that is used by the device 108.Further, the device configuration analyzer 102 generate, for the entity,a response that includes an indication of the ascertained configurationfile that is used by the device 108.

According to examples disclosed herein, further to the sending, over thenetwork 104, the configuration file to the device 108 to modify, basedon the sent configuration file, the configuration for the device 108,the device configuration analyzer 102 may determine whether the sentconfiguration file is of a same file type present in a command queue forthe device 108. Based on a determination that the sent configurationfile is of the same file type present in the command queue for thedevice 108, the device configuration analyzer 102 may determine acommand status of a command associated with the sent configuration file,and implement, based on the determined command status, a retry operationwith respect to the command queue for the device 108 for the sentconfiguration file.

According to examples disclosed herein, further to the sending, over thenetwork 104, the configuration file to the device 108 to modify, basedon the sent configuration file, the configuration for the device 108,the device configuration analyzer 102 may determine whether the sentconfiguration file is of a same file type present in a command queue forthe device. Further, based on a determination that the sentconfiguration file is not of the same file type present in the commandqueue for the device 108, the device configuration analyzer 102 mayimplement a retry operation with respect to the command queue for thedevice 108 for the sent configuration file.

FIG. 2 illustrates further details of the architecture of the system100, according to an example of the present disclosure.

Referring to FIG. 2, the system 100 may include the global configurationlibrary 124, the device-to-configuration library 126, and theapplication file system 128, each interconnected as disclosed hereinwith respect to IoT devices (e.g., devices 108(a)-108(n)), as well asthird party applications. The third party applications may provideand/or request information such as configuration information and/orconfiguration files from the IoT devices. The transfer of suchconfiguration information and/or configuration files may be managed bythe system 100 as disclosed herein.

FIG. 3 illustrates further details of the architecture of the system100, including a global configuration library and adevice-to-configuration library, according to an example of the presentdisclosure.

Referring to FIG. 3, examples of the global configuration library 124,the device-to-configuration library 126, and the application file system128 are illustrated. The global configuration library 124 may includeinformation such as a configuration file type (e.g., switch, geofence,etc.), associated hash values (e.g., SHA-1 value KAUCHSJ9182630, etc.),and record identification numbers for the configuration files (e.g., 1,2, 3, etc.). Similarly, the device-to-configuration library 126 mayinclude information such as the device identification (e.g., Device 121,Device 122, etc.), configuration file type (e.g., switch, geofence,etc.), and record identification numbers for the configuration files(e.g., 1, 2, 3, etc.). In this manner, the entries of thedevice-to-configuration library 126 may store a reference to the globalconfiguration library 124 for each configuration file on a device 108.Further, for the example device illustrated at 300, at 302, aconfiguration may be created in a third party application. Theconfiguration may include a geofencing engine with a file type ofgeofence configuration, and a hash value of ABCDEFG1234567 (in thisexample, a SHA-1 value). At 304, the third party application may informthe system 100 to send the configuration to the device at 300. At theglobal configuration library 124, if needed, a new record may be addedto the global configuration library 124. Further, at thedevice-to-configuration library 126, the configuration and the device(e.g., Device 123) may be associated. At the device at 300, theconfiguration may be queued as disclosed herein for the device.

FIG. 4 illustrates a device configuration request flow to illustrateoperation of the system 100, according to an example of the presentdisclosure.

The device configuration request flow may be utilized when a devicesends the system 100 a new configuration file status message.

With respect to FIGS. 4-10, possible statuses from the device mayinclude “FILE_NOT_SUPPORTED=0” where the device does not know how tohandle the configuration file in question, “CURRENT_FILE=1” where thesystem 100 and the device are in agreement, “FILE_SYNC_PENDING=2” wheresomething needed to be synced and an incoming request is expected,“NO_FILE_PRESENT=3” where the configuration file that was requested doesnot exist on the device or in the system 100, “FILE_DELETE_SUCCESS=4”,and “FILE_SYNC_INTERNAL_ERROR=5” where an error occurred.

Further, possible statuses recorded in the system 100 may include a“Synced_missing_ob_file” where “ob” represents a device,“unknown_file_requested” where an unknown configuration file may berequested by a device, “known_file_on_new_device”, “device_in_sync”which corresponds to device status=“CURRENT_FILE”, “Sync_with_device”which corresponds to device status=“FILE_SYNC_PENDING”, and“Sync_process_failed” which may represent a fail out status.

Referring to FIG. 4, at block 400, a device-originated sync request maybe received. In this regard, parameters in the device status message mayinclude the “File Type Number” of the configuration file, request type“REQUEST_FILE or DELETE_FILE”, and Secure Hash Algorithm 1 (SHA-1) thatrepresents the hash type of the configuration file type being processed.

At block 402, the associated protobuf sync request message may be parsedaccording to a proto file definition.

At block 404, the message data may be stored in a separate table by thedevice for later reference.

At block 406, a determination may be made as to whether the hash syncprocess is on. If the sync process is off, the sync process will not beused. The sync process may not be used if there is a critical error orflaw in the process.

At block 408, based on a determination at block 406 that the hash syncprocess is not on, a “SYNC_RESPONSE=1 (CURRENT_FILE)” may be returned tothe device. When this status is received by the device, it should stopthe sync process.

At block 410, based on a determination at block 406 that the hash syncprocess is on, a determination may be made as to whether the file typeis supported by hash sync process. In this regard, certain legacyconfiguration file types designed and built before the hash sync processwas built may not be supported.

At block 412, based on a determination at block 410 that the file typeis not supported by the hash sync process, a “SYNC_RESPONSE=0(FILE_NOT_SUPPORTED)” may be returned to the device. This status mayinform the device that the configuration file type it is requesting isnot supported by the hash sync process. This status may further stop thesync process.

At block 414, a determination may be made as to whether the hash fieldof the request is populated. In this regard, a determination of yes (Y)means that a configuration file type exists on the device, and adetermination of no (N) means that a configuration file type does notexist on the device.

With respect to blocks 416-426 discussed below, these blocks mayrepresent a flow where a device (e.g., device 108) requests an existingconfiguration file from the system 100. In this regard, the device mayhave lost its configuration file, corrupted its local copy of theconfiguration file, or only received a partial copy of the configurationfile due to connection disturbances with the system 100, and thusrequests a new copy. The device also may need to ‘re-sync’ with thesystem 100 after it has been placed on a new piece of equipment.Further, the device may request a configuration file that it actuallydoes not need.

At block 416, the device-to-configuration library 126 may be queried bydevice and configuration file type. The purpose of this query is todetermine whether the device already has a configuration of that type.

At block 418, a determination may be made as to whether a result isreturned. In this regard, a yes (Y) may indicate that the system 100 hasa copy of the configuration in the application file system 128 that ismissing on the device, and a no (N) may indicate that the configurationbeing requested by the device does not exist in the system 100 or on thedevice.

At block 420, based on a determination at block 418 that no result isreturned (e.g., no configuration file exists on the device or in theapplication file system 128), a “SYNC_RESPONSE=3” (no file present) maybe returned to the device. This sync response may end the sync process.

At block 422, based on a determination at block 418 that a result isreturned (e.g., the system 100 has a configuration file that is missingon the device), “sha_sync.status” may be set to “synced_missing_ob_file”which means that a configuration was missing on the device but it wasrestored by the sync process. In this regard “ob” may represent adevice, and the “synced_missing_ob_file” may represent a status recordedin the system 100.

At block 424, a message status=MO_req_file_synced may be created, wherethe associated file type may represent the ‘sync status message’ typewhich informs third party applications of the status of a sync process.

At block 426, the configuration file that was identified at block 416may be sent to the device, and the sync process may end.

At block 428, the device-to-configuration library 126 relationship bymay be queried by device and configuration file type.

At block 430, a determination may be made as to whether a result isreturned. In this regard, a yes (Y) may indicate that the system 100 andthe device have a record for that configuration type on that device (butpossibly not the same exact configuration file), and a no (N) mayindicate that the device has a configuration file type that the system100 does not have.

With respect to blocks 432-446 discussed below, these blocks mayrepresent a flow where the system 100 learns that a device has apreviously-unknown configuration file. In this regard, the configurationfile may have been uploaded locally. If the configuration file iscompletely new, the system 100 may request a copy in order to add it tothe device-to-configuration library 126, the global configurationlibrary 124, and the application file system 128.

At block 432, the global configuration library 124 may be queried by thehash algorithm in the request message to determine whether thisconfiguration file already exists in the global configuration library124.

At block 434, a determination may be made as to whether theconfiguration file exists the global configuration library 124.

At block 436, based on a determination at block 434 that theconfiguration file does not exist in the global configuration library124, a “SYNC_RESPONSE=1” (e.g., current file) may be returned. This mayinform the device that it has the correct configuration, since thesystem 100 does not have a record of that configuration file in theglobal configuration library 124. This also means that is a completelynew and unique configuration file may be applied locally at the device.This new configuration file may be requested from the device by thesystem 100 in block 440.

At block 438, the configuration status 118 may be set equal to“unknown_file_requested”. The “unknown_file_requested” may represent astatus recorded by the system 100 for a request by a device of acompletely new configuration file.

At block 440, the sync request message may be generated with the sameconfiguration file type and a blank hash field. The generation of thesync request message may prompt the device to send the configurationfile to the system 100.

At block 442, processing may continue to the “Device-Submit” flow forwhen the device replies with the configuration file, as shown in FIG. 7.

At block 444, based on a determination at block 434 that theconfiguration file exists in the global configuration library 124, a“SYNC_RESPONSE=1” (e.g., current file) may be returned to the device.

At block 446, the configuration status 118 may be set equal to“known_file_on_new_device”. This means that an existing configurationfile was discovered on a new device. In this regard, the“known_file_on_new_device” may represent a status recorded by the system100.

At block 448, the hash value in the device-to-configuration library 126may be compared to the hash value in the message from the device.

At block 450, a determination may be made as to whether the hash valuesmatch.

With respect to blocks 452-456 discussed below, these blocks mayrepresent a flow where the system 100 confirms that device is syncedcorrectly (e.g., no action taken, the system 100 indicates to the devicethat the system 100 and the device are in sync).

At block 452, based on a determination at block 450 that the hash valuesmatch (e.g., the device and the system 100 are in sync), a“SYNC_RESPONSE=1” (current file) may be returned.

At block 454, the configuration status 118 may be set to“device_in_sync” to create a record in the device configuration statuscontroller 116 that the system 100 and the device are in sync. In thisregard, the “device_in_sync” may correspond to a response status of“CURRENT_FILE” returned to the device.

At block 456, a ‘sync status message’ type which informs third partiesthe status of a configuration or a device may be generated with status“MO_req_in_sync”, which may tell third parties that the device requestedan updated configuration but the device already had the correctconfiguration.

With respect to blocks 458-466 discussed below, these blocks mayrepresent a flow where a device (e.g., the device 108) and the system100 are not in sync, but the device owns the configuration type. Theconfiguration type owner (e.g., the system 100, the device 108, orshared) may have permission to update that type of configuration. Inregard to device ownership, the configuration may be uploaded locallyonto the device 108, the system 100 may confirm the out-of-synccondition with the device, and then request the new configuration forthe system 100 to store in application file system 128.

At block 458, a determination may be made as to whether the device hasownership of the configuration type.

At block 460, based on a determination at block 458 that the device hasownership of the configuration type, a “SYNC_RESPONSE=2” (file syncpending) may be returned.

At block 462, the configuration status 118 may be set to equal to“sync_with_device”, which creates a record in the applicationconfiguration status 118 that the application must request theconfiguration file from the device. In this regard, the“sync_with_device” in the application configuration status 118 maycorrespond to a response to the device with a status of“FILE_SYNC_PENDING”.

At block 464, a sync request may be sent from the system 100 to thedevice with the same configuration file type but with a hash value. Theblank hash value may prompt the device to reply with its local copy ofthe configuration file.

At block 466, further processing may continue to the “Device-Submit”flow for when the device replies with the configuration file.

At block 468, a determination may be made as to whether the ownership isequal to the system 100. If the system 100 has ownership of aconfiguration, then the configuration may only be updated by the system100. If the answer to block 468 is yes, the system 100 may assert itspermissions over the device by re-sending the configuration file inblock 472.

With respect to block 470 discussed below, this block may represent aflow where the device (e.g., device 108) and the system 100 are not insync, and the system 100 has ownership of the configuration type. Inthis regard, the system 100 may queue the configuration file that it hasstored in the application file system 128 for that device and thatconfiguration type (as recorded in the device-to-configuration library126).

At block 470, based on a determination at block 468 that the mastershipis equal to the system 100, the configuration status 118 may be set toequal to “sync_with_device”.

At block 472, the configuration file identified at block 428 may bequeued to the device (e.g., the device 108).

At block 474, a determination may be made as to whether the ownership isshared. Shared ownership means that both the system 100 and the devicehave permission to update the configuration.

At block 476, based on a determination at block 474 that the ownershipis not equal to shared, a “SYNC_RESPONSE=1” (current file) may bereturned in order to stop the sync process on the device since theprocess has failed in the system 100.

At block 478, the configuration status 118 may be set equal to“sync_process_failed” in the application configuration status 118. Inthis regard, the “sync_process_failed” may represent to a fail outstatus of the sync process where there was a logical or proceduralerror.

At block 480, processing with respect to the device configurationrequest flow may be completed.

FIG. 5 illustrates a third party request flow to illustrate operation ofthe system 100, according to an example of the present disclosure.

The third party request flow may be utilized when a third partyapplication requests that a new configuration is sent to or deleted froma device.

Referring to FIG. 5, at block 500, a third party may invoke the POST orDELETE method of a “Configuration File” application programminginterface (API). In this regard, API parameters may include “file_type”that represents a configuration file type, “config_file” may representthe contents of a configuration itself, and “sha_1” may represent thehash algorithm used to verify a configuration file, if the configurationhas been sent to the system 100 before.

At block 502, a determination may be made as to whether the hash syncprocess is on.

At block 504, based on a determination at block 502 that the hash syncprocess is not on, further processing may continue to a legacyconfiguration file management process.

At block 506, based on a determination at block 502 that the hash syncprocess is on, a determination may be made as to whether theconfiguration file type is supported by hash sync.

At block 508, based on a determination at block 506 that theconfiguration file type is supported by hash sync process, adetermination may be made as to whether the aforementioned API isinvoked with config_file.

With respect to blocks 510-514 discussed below, these blocks mayrepresent a flow where the system 100 determines whether theconfiguration is new or existing. In this regard, if the system 100 hasnot seen the configuration before, the configuration will be saved tothe application file system 128, and otherwise, the system 100 may use acopy that is already present in the application file system 128.

At block 510, based on a determination at block 508 that the API isinvoked with config_file (the contents of the configuration fileitself), the configuration file may be decoded for further processing(e.g., base64).

At block 512, the hash of the configuration file may be determined.

At block 514, the global configuration library 124, thedevice-to-configuration library 126, and the application file system 128may be analyzed by the hash determined at block 512, and if the hashdoes not exist, it may be saved to the application file system 128.

At block 516, based on a determination at block 508 that the API is notinvoked with config_file (the configuration file itself), the globalconfiguration library 124 may be analyzed by the hash. If the hashexists in the global configuration library 124, then processing maycontinue, and otherwise, a third party configuration library may becalled to retrieve the contents of the configuration file.

At block 518, the device configuration controller 120 may be called toretrieve additional information about the device. This information maybe used after block 518 to send the configuration file to the device.

At block 520, a determination may be made as to whether a DELETE methodwas invoked for the Configuration File API. If the DELETE method wasinvoked by the third party, then the intent of the third party may be toremove the configuration file from the device.

At block 522, based on a determination at block 520 that the DELETEmethod was invoked, the sync request message may be queued to thedevice. This sync request message may request the device to delete theconfiguration file type from the device.

At block 524, based on a determination at block 520 that the DELETEmethod was not invoked, the device-to-configuration library 126 may bequeried by device and file type in order to determine if a configurationfile of that type already exists on the device.

At block 526, a determination may be made as to whether a result (e.g.,from block 524) was returned. In this regard, a yes (Y) may indicatethat a configuration file of that type has been queued before for thedevice, and a no (N) may indicate that the configuration file type hasnot been queued before for the device.

At block 528, a determination may be made as to whether the hash fromblock 512 matches the hash from the device-to-configuration library 126.

With respect to blocks 530-532 discussed below, these blocks mayrepresent a flow where a third party is requesting to send aconfiguration that is already on the device. In this regard, the system100 may update the ‘last updated’ timestamp and generate a replysuccessfully to the third party. Further, no information is queued forthe device (since the device already has the configuration file).

At block 530, based on a determination at block 528 that the hash fromblock 512 matches the hash from the device-to-configuration library 126,a timestamp for the hash/device identification record may be updated inthe device-to-configuration library 126.

At block 532, a ‘sync status message’ that informs third parties of thestatus of a configuration or a device may be generated, with a messagestatus as “no_sync_needed”.

At block 534, further processing may proceed to the global configurationlibrary 124 check flow of FIG. 9.

At block 536, further processing may proceed to the command queue flowof FIG. 8.

At block 538, processing with respect to the third party request flowmay be completed.

FIG. 6 illustrates a third party application request flow to illustrateoperation of the system 100, according to an example of the presentdisclosure.

The third party application request flow may be utilized when a thirdparty application requests a configuration file from the device. If thesystem 100 already knows which configuration files are on a device (fromdevice-to-configuration library 126), the system 100 may reply with thesystem's copy (stored in file system 128) instead of requesting a newconfiguration file from the device.

Referring to FIG. 6, at block 600, a third party may request aconfiguration file from a device (e.g., device 108)

At block 602, a determination may be made as to whether the hash syncprocess is on.

At block 604, based on a determination at block 602 that the hash syncprocess is not on, a legacy configuration request process may be used.

At block 606, a response to the request with an “OK” may be generated.

At block 608, based on a determination at block 602 that the hash syncprocess is on, a determination may be made as to whether theconfiguration type is supported by the hash sync process.

With respect to blocks 610-618 discussed below, these blocks mayrepresent a flow where a third party requests a configuration type whichis owned by the device, and the system 100 automatically requests theconfiguration from the device.

At block 610, a determination may be made as to whether theconfiguration type being requested is owned by the device. If so, theconfiguration file may be requested directly from the device instead ofusing system 100's copy from the application file system 128.

At block 612, based on a determination at block 610 that a configurationfile type is owned by the device, a hash request message may begenerated with file type and a blank hash field. The blank hash fieldmay prompt the device to send its copy of the configuration file to thesystem 100.

At block 614, a flow may be initiated with the request from block 612.

At block 616, a response may be generated to the requester with OK.

At block 618, further processing may proceed as disclosed herein withrespect to FIG. 7, starting at block 700, when the device responds withthe configuration file.

At block 620, a query may be made to the device-to-configuration library126 to determine whether there is a record for the configuration filetype for the device.

With respect to blocks 622-628 discussed below, these blocks mayrepresent a flow where a third party requests a configuration file thatthe system 100 already has on record for the device. In this regard, theconfiguration file may be pulled from the system 100, and not requestedfrom the device. Further, all responses to third parties andconfiguration file data may appear the same to integrating systems as ifthe file was requested from the device.

At block 622, a determination may be made as to whether a result isreturned for the query at block 620.

At block 624, the configuration file may be retrieved from theapplication file system 128 by the hash.

At block 626, the configuration file may be sent to the third partyrequester

At block 628, a response may be generated for the requester indicating“OK”, thus communicating that the process was executed successfully.

At block 630, processing with respect to the application request flowmay be completed.

FIG. 7 illustrates a device originated flow to illustrate operation ofthe system 100, according to an example of the present disclosure.

The device originated flow may be utilized when a device sends aconfiguration file to the system 100. This may occur if a configurationis applied at the device (whether valid or malicious) and sent to thesystem 100. It may also occur if a configuration file is requested fromthe device as a result of a third party request (e.g., see FIG. 6).

Referring to FIG. 7, at block 700, a device may send a configurationfile to the system 100.

At block 702, a determination may be made as to whether the hash syncprocess is on.

At block 704, based on a determination at block 702 that the hash syncprocess is on, a determination may be made as to whether theconfiguration file type is supported by the hash sync process.

At block 706, based on a determination at block 704 that theconfiguration file type is supported by the hash sync process, adetermination may be made as to whether the file type ownership is equalto DEVICE.

At block 708, based on a determination at block 706 that theconfiguration file type ownership is equal to DEVICE, the applicationfile system 128 may be checked, and if the configuration file does notyet exist in the application file system 128, a save operation may beperformed.

At block 710, further processing may proceed to the global filelibrary-check sub-process flow of FIG. 9.

At block 712, a hash may be calculated for the configuration file sentby the device.

At block 714, the device-to-configuration library 126 may be queried bydevice and configuration type.

At block 716, a determination may be made as to whether a result isreturned from the device-to-configuration library 126. In this regard, ayes (Y) may indicate that the system 100 and the device 108 both have arecord for that configuration type, and a no (N) may indicate that thedevice has a configuration type that the system 100 does not have.

With respect to blocks 718-722 discussed below, these blocks mayrepresent a flow where a device sends a configuration file to the system100. If the configuration file is the same as recorded in system 100, noaction is taken, but if the configuration file is different thanexpected, the system 100 may request the new configuration file from thedevice, so that system 100 may store a copy and update the applicationfile system 128.

At block 718, the hash found in the device-to-configuration library 126may be compared to the hash of the configuration file sent by thedevice. This is the configuration file sent by the device in block 700and the hash calculated in block 712.

At block 720, a determination may be made as to whether the hash valuesmatch. If the values match, this may confirm that the device 108 and thesystem 100 are in sync, and no action is needed. If the values do notmatch, this may mean that a configuration file was somehow applied tothe device, but the device does not own that configuration type (asdetermined in block 706). The system 100 may then re-synchronize withthe device by sending it the configuration file that the system 100 hason that device.

At block 722, based on a determination at block 720 that the hash valuesdo not match, the existing configuration file found in thedevice-to-configuration library 126 may be retrieved from theapplication file system 128.

At block 724, the configuration file retrieved in block 722 may be sentto the device so that the device is in sync with the system 100

At block 726, further processing may proceed to the global filelibrary-check sub-process flow of FIG. 9.

At block 728, processing with respect to the device originated flow maybe completed.

FIG. 8 illustrates a command queuing sub-process flow to illustrateoperation of the system 100, according to an example of the presentdisclosure.

The command queuing sub-process flow may provide for sending of theconfiguration file for the device, and include retry logic associatedwith that command if the command fails on the first or second attempt.

Referring to FIG. 8, at block 800, processing with respect to thecommand queuing sub-process flow may commence.

At block 802, an hash response message may be generated with“SYNC_RESPONSE=FILE_SYNC_PENDING”, which may notify the device thatsystem 100 will be sending a configuration file.

At block 804, a determination may be made as to whether the file typebeing queued is a configuration file. This may ensure that the syncresponse message types are not processed the same manner as theconfiguration file types.

With respect to blocks 806-818 discussed below, these blocks mayrepresent a flow of the logic for queuing a configuration file, as wellas the retry logic for re-queuing the configuration if it fails at thedevice.

At block 806, a determination may be made as to whether a configurationfile of the same type is already present in the device's command queue.

At block 808, the older duplicate configuration file type may be deletedfrom the command queue.

At block 810, the configuration file may be queued.

At block 812, further to block 810, a determination may be made as towhether a device acknowledges that the configuration file wassuccessfully downloaded and applied.

At block 814, based on a determination at block 812 that the commandresponse is not successful, the command status may be set to failurebefore trying to re-queue the configuration file a second or third time(proceeding through transition point ‘C’)

At block 816, the retry counter may be incremented.

At block 818, a determination may be made as to whether the retrycounter is greater than two, or another specified value. If the retrycounter is less than two, processing may revert to block 810.

At block 820, based on a determination that the retry counter is greaterthan two, sync_status in application configuration status 118 may be setto SYNC_FAIL since all retries have failed and the process must end.

At block 822, a sync_status=SYNC_FAIL message may be generated to notifythird party applications that the hash sync process has failed for thedevice

At block 824, processing with respect to the command queuing sub-processflow may be completed.

FIG. 9 illustrates a global file library-check sub-process flow toillustrate operation of the system 100, according to an example of thepresent disclosure.

The global file library-check sub-process flow may include the logic forutilization of the global file library to determine whether the processflow is encountering a new configuration file or an existingconfiguration file.

Referring to FIG. 9, the logic of FIG. 9 may represent a reusable pieceof logic to analyze the global configuration library 124. In thisregard, the outcome of the check may be either that thedevice-to-configuration library 126 is updated or the configuration doesnot exist at all, and thus a new global configuration library 124 recordmay be created and the relationship may be established.

At block 900, processing with respect to the global configurationlibrary 124 may commence.

At block 902, the global configuration library 124 may be queried byconfiguration file type and hash value (e.g., the device configurationhash value 110)

At block 904, a determination may be made as to whether a result isreturned. If a result is returned, the configuration file may have beensent to or from the system 100 in the past. If no record is returned,the configuration file may be determined to be completely new to thesystem 100.

At block 906, based on a determination at block 904 that a result is notreturned, the configuration file type and hash value may be saved to theglobal configuration library 124 so that it may be referenced and usedin the future if it is sent to or from another device.

At block 908, a relationship may be created between the configurationfile and the device in the device-to-configuration library 126.

At block 910, based on a determination at block 904 that a result isreturned, the device-to-configuration library 126 may be queried byconfiguration file type and device to determine if there is already arecord of that configuration file type for that device.

At block 912, with respect to the record from block 910, a determinationmay be made as to whether there is an existing file type for the givendevice.

At block 914, the value of the hash may be updated for the given deviceand configuration type. This may represent that the device has a newversion of a previously existing configuration type.

At block 916, processing with respect to the global configurationlibrary 124 may be completed.

FIG. 10 illustrates a device initiated delete flow to illustrateoperation of the system 100, according to an example of the presentdisclosure.

The device initiated delete flow may be utilized by a device to handle aconfiguration file when the configuration file is deleted locally, andthe system 100 is to be updated of this change. If the local-delete isnot permitted, the system 100 may rectify the situation by re-queuingthe configuration file that the device is trying to delete.

Referring to FIG. 10, the logic of FIG. 10 may be used when a devicerequests the system 100 to delete a configuration record (as long as thedevice has permissions to do so for that configuration type).

At block 1000, a device may send an hash response message withSYNC_RESPONSE=FILE_DELETE_SUCCESS.

At block 1002, the device-to-configuration library 126 may be queried bydevice and configuration file type.

At block 1004, a determination may be made as to whether a record isfound.

At block 1006, based on a determination at block 1004 that a record isfound, the record may be deleted.

At block 1008, processing with respect to the device initiated deleteflow may be completed.

FIGS. 11-13 respectively illustrate a block diagram 1100, a flowchart ofa method 1200, and a further block diagram 1300 for hash based deviceconfiguration management, according to examples. The block diagram 1100,the method 1200, and the block diagram 1300 may be implemented on thesystem 100 described above with reference to FIG. 1 by way of exampleand not limitation. The block diagram 1100, the method 1200, and theblock diagram 1300 may be practiced in other systems. In addition toshowing the block diagram 1100, FIG. 11 shows hardware of the system 100that may execute the instructions of the block diagram 1100. Thehardware may include a processor 1102, and a memory 1104 storing machinereadable instructions that when executed by the processor cause theprocessor to perform the instructions of the block diagram 1100. Thememory 1104 may represent a non-transitory computer readable medium.FIG. 12 may represent a method for implementing a hash based deviceconfiguration management, and the steps of the method. FIG. 13 mayrepresent a non-transitory computer readable medium 1302 having storedthereon machine readable instructions to provide a hash based deviceconfiguration management. The machine readable instructions, whenexecuted, cause a processor 1304 to perform the instructions of theblock diagram 1300 also shown in FIG. 13.

The processor 1102 of FIG. 11 and/or the processor 1304 of FIG. 13 mayinclude a single or multiple processors or other hardware processingcircuit, to execute the methods, functions and other processes describedherein. These methods, functions and other processes may be embodied asmachine readable instructions stored on a computer readable medium,which may be non-transitory (e.g., the non-transitory computer readablemedium 1302 of FIG. 13), such as hardware storage devices (e.g., RAM(random access memory), ROM (read only memory), EPROM (erasable,programmable ROM), EEPROM (electrically erasable, programmable ROM),hard drives, and flash memory). The memory 1104 may include a RAM, wherethe machine readable instructions and data for a processor may resideduring runtime.

Referring to FIGS. 1-11, and particularly to the block diagram 1100shown in FIG. 11, the memory 1104 may include instructions 1106 toascertain, over a network 104, a device configuration status 106 of adevice 108 of a plurality of devices, and a device configuration hashvalue 110 associated with a configuration file 112 for the device 108.

The processor 1102 may fetch, decode, and execute the instructions 1108to determine whether the device configuration hash value 110 matches anapplication configuration hash value 114.

The processor 1102 may fetch, decode, and execute the instructions 1110to modify, based on a determination that the device configuration hashvalue 110 matches the application configuration hash value 114, anapplication configuration status 118 for the device 108 to correspond tothe device configuration status 106 of the device 108.

The processor 1102 may fetch, decode, and execute the instructions 1112to determine, based on a determination that the device configurationhash value 110 does not match the application configuration hash value114, whether the device 108 has permission to locally modify theconfiguration for the device 108.

Based on a determination that the device 108 does not have permission tolocally modify the configuration for the device 108, the processor 1102may fetch, decode, and execute the instructions 1114 to send, over thenetwork 104, a configuration file to the device 108 to modify, based onthe sent configuration file, the configuration for the device 108.

Based on a determination that the device 108 has permission to locallymodify the configuration for the device 108, the processor 1102 mayfetch, decode, and execute the instructions 1116 to request, over thenetwork 104, the configuration file that is associated with the deviceconfiguration hash value 110 and is used by the device 108 to modify theconfiguration for the device 108, and update, upon receipt, over thenetwork 104, of the requested configuration file, a configuration record122 associated with the device 108 based on the requested configurationfile.

Referring to FIGS. 1-10 and 12, and particularly FIG. 12, for the method1200, at block 1202, the method may include ascertaining, over a network104, a device configuration status 106 of a device 108 of a plurality ofdevices that include Internet of Things (IoT) devices, and a deviceconfiguration hash value 110 associated with a configuration file 112for the device 108.

At block 1204, the method may include determining whether the deviceconfiguration hash value 110 matches an application configuration hashvalue 114.

At block 1206, the method may include modifying, based on adetermination that the device configuration hash value 110 matches theapplication configuration hash value 114, an application configurationstatus 118 for the device 108 to correspond to the device configurationstatus 106 of the device 108.

At block 1208, the method may include determining, based on adetermination that the device configuration hash value 110 does notmatch the application configuration hash value 114, whether the device108 has permission to locally modify the configuration for the device108.

At block 1210, based on a determination that the device 108 does nothave permission to locally modify the configuration for the device 108,the method may include sending, over the network 104, a configurationfile to the device 108 to modify, based on the sent configuration file,the configuration for the device 108.

At block 1212, based on a determination that the device 108 haspermission to locally modify the configuration for the device 108, themethod may include requesting, over the network 104, the configurationfile that is associated with the device configuration hash value 110 andis used by the device 108 to modify the configuration for the device108, and updating, upon receipt, over the network 104, of the requestedconfiguration file, a configuration record 122 associated with thedevice 108 based on the requested configuration file.

Referring to FIGS. 1-10 and 13, and particularly FIG. 13, for the blockdiagram 1300, the non-transitory computer readable medium 1302 mayinclude instructions 1306 to ascertain, over a network 104, a deviceconfiguration status 106 of a device 108 of a plurality of devices, anda device configuration hash value 110 associated with a configurationfile 112 for the device 108.

The processor 1304 may fetch, decode, and execute the instructions 1308to determine whether the device configuration hash value 110 matches anapplication configuration hash value 114.

The processor 1304 may fetch, decode, and execute the instructions 1310to modify, based on a determination that the device configuration hashvalue 110 matches the application configuration hash value 114, anapplication configuration status 118 for the device 108 to correspond tothe device configuration status 106 of the device 108.

The processor 1304 may fetch, decode, and execute the instructions 1312to determine, based on a determination that the device configurationhash value 110 does not match the application configuration hash value114, whether the device 108 has permission to locally modify theconfiguration for the device 108.

Based on a determination that the device 108 does not have permission tolocally modify the configuration for the device 108, the processor 1304may fetch, decode, and execute the instructions 1314 to send, over thenetwork 104, a configuration file to the device 108 to modify, based onthe sent configuration file, the configuration for the device 108.

The processor 1304 may fetch, decode, and execute the instructions 1316to determine whether the sent configuration file is of a same file typepresent in a command queue for the device 108.

Based on a determination that the sent configuration file is of the samefile type present in the command queue for the device 108, the processor1304 may fetch, decode, and execute the instructions 1318 to determine acommand status of a command associated with the sent configuration file,and implement, based on the determined command status, a retry operationwith respect to the command queue for the device 108 for the sentconfiguration file.

What has been described and illustrated herein is an example along withsome of its variations. The terms, descriptions and figures used hereinare set forth by way of illustration only and are not meant aslimitations. Many variations are possible within the spirit and scope ofthe subject matter, which is intended to be defined by the followingclaims—and their equivalents—in which all terms are meant in theirbroadest reasonable sense unless otherwise indicated.

What is claimed is:
 1. A system comprising: a device configurationanalyzer, executed by at least one hardware processor, to ascertain,over a network, a device configuration status of a device of a pluralityof devices, and a device configuration hash value associated with aconfiguration file for the device, and determine whether the deviceconfiguration hash value matches an application configuration hashvalue; a device configuration status controller, executed by the atleast one hardware processor, to modify, based on a determination thatthe device configuration hash value matches the applicationconfiguration hash value, an application configuration status for thedevice to correspond to the device configuration status of the device;and a device configuration controller, executed by the at least onehardware processor, to determine, based on a determination that thedevice configuration hash value does not match the applicationconfiguration hash value, whether the device has permission to locallymodify the configuration for the device, based on a determination thatthe device does not have permission to locally modify the configurationfor the device, send, over the network, a configuration file to thedevice to modify, based on the sent configuration file, theconfiguration for the device, and based on a determination that thedevice has permission to locally modify the configuration for thedevice, request, over the network, the configuration file that isassociated with the device configuration hash value and is used by thedevice to modify the configuration for the device, and update, uponreceipt, over the network, of the requested configuration file, aconfiguration record associated with the device based on the requestedconfiguration file.
 2. The system according to claim 1, wherein thedevice configuration hash value is a Secure Hash Algorithm 1 hash, andthe application configuration hash value is Secure Hash Algorithm
 1. 3.The system according to claim 1, wherein the device includes an Internetof Things (IoT) device.
 4. The system according to claim 1, wherein thedevice configuration analyzer is to: further to the sending, over thenetwork, the configuration file to the device to modify, based on thesent configuration file, the configuration for the device, ascertain,from the device and over the network, the device configuration status ofthe device, and the device configuration hash value associated with theconfiguration file that is used to modify the configuration for thedevice; and determine whether the device configuration hash valueassociated with the configuration file that is used to modify theconfiguration for the device matches the application configuration hashvalue.
 5. The system according to claim 1, wherein the deviceconfiguration analyzer is to determine whether the device configurationhash value matches the application configuration hash value byaccessing, over the network, a global configuration library that storesapplication configuration hash values including the applicationconfiguration hash value, wherein the application configuration hashvalues are mapped to associated configuration files, accessing, over thenetwork, a device-to-configuration library that stores a reference tothe global configuration library for each configuration file on adevice, and ascertaining, based on the access to the globalconfiguration library and the device-to-configuration library, theapplication configuration hash value associated with the device forwhich the device configuration hash value is ascertained.
 6. The systemaccording to claim 1, wherein the device configuration controller is to:ascertain, over the network, a request to update the configuration forthe device; ascertain, over the network, another device configurationhash value associated with the request to update the configuration forthe device; retrieve, over the network, a configuration file associatedwith the another device configuration hash value; and send, to thedevice and over the network, the retrieved configuration file associatedwith the another device configuration hash value to update theconfiguration for the device.
 7. The system according to claim 6,wherein the device configuration analyzer is to: notify, over thenetwork, an entity associated with the request to update theconfiguration for the device, the device configuration status of thedevice upon completion of the update, based on the retrievedconfiguration file associated with the another device configuration hashvalue, of the configuration for the device.
 8. The system according toclaim 1, wherein the device configuration analyzer is to: receive, overthe network, a request from an entity for the configuration file that isused by the device; determine, based on the received request from theentity for the configuration file that is used by the device, whetherthe configuration file that is used by the device is known or unknown;and based on a determination that the configuration file that is used bythe device is known, generate, for the entity, a response that includesan indication of the configuration file that is used by the device. 9.The system according to claim 8, wherein the device configurationanalyzer is to: based on a determination that the configuration filethat is used by the device is unknown, ascertain, from the device, theconfiguration file that is used by the device; and generate, for theentity, a response that includes an indication of the ascertainedconfiguration file that is used by the device.
 10. The system accordingto claim 1, wherein the device configuration analyzer is to: further tothe sending, over the network, the configuration file to the device tomodify, based on the sent configuration file, the configuration for thedevice, determine whether the sent configuration file is of a same filetype present in a command queue for the device, and based on adetermination that the sent configuration file is of the same file typepresent in the command queue for the device, determine a command statusof a command associated with the sent configuration file, and implement,based on the determined command status, a retry operation with respectto the command queue for the device for the sent configuration file. 11.The system according to claim 1, wherein the device configurationanalyzer is to: further to the sending, over the network, theconfiguration file to the device to modify, based on the sentconfiguration file, the configuration for the device, determine whetherthe sent configuration file is of a same file type present in a commandqueue for the device, and based on a determination that the sentconfiguration file is not of the same file type present in the commandqueue for the device, implement a retry operation with respect to thecommand queue for the device for the sent configuration file.
 12. Acomputer implemented method comprising: ascertaining, over a network, adevice configuration status of a device of a plurality of devices thatinclude Internet of Things (IoT) devices, and a device configurationhash value associated with a configuration file for the device;determining whether the device configuration hash value matches anapplication configuration hash value; modifying, based on adetermination that the device configuration hash value matches theapplication configuration hash value, an application configurationstatus for the device to correspond to the device configuration statusof the device; determining, based on a determination that the deviceconfiguration hash value does not match the application configurationhash value, whether the device has permission to locally modify theconfiguration for the device; based on a determination that the devicedoes not have permission to locally modify the configuration for thedevice, sending, over the network, a configuration file to the device tomodify, based on the sent configuration file, the configuration for thedevice; and based on a determination that the device has permission tolocally modify the configuration for the device, requesting, over thenetwork, the configuration file that is associated with the deviceconfiguration hash value and is used by the device to modify theconfiguration for the device, and updating, upon receipt, over thenetwork, of the requested configuration file, a configuration recordassociated with the device based on the requested configuration file.13. The method according to claim 12, wherein the device configurationhash value is a Secure Hash Algorithm 1 value, and the applicationconfiguration hash value is Secure Hash Algorithm
 1. 14. The methodaccording to claim 12, further comprising: further to the sending, overthe network, the configuration file to the device to modify, based onthe sent configuration file, the configuration for the device,ascertaining, from the device and over the network, the deviceconfiguration status of the device, and the device configuration hashvalue associated with the configuration file that is used to modify theconfiguration for the device; and determining whether the deviceconfiguration hash value associated with the configuration file that isused to modify the configuration for the device matches the applicationconfiguration hash value.
 15. The method according to claim 12, whereindetermining whether the device configuration hash value matches theapplication configuration hash value further comprises: accessing, overthe network, a global configuration library that stores applicationconfiguration hash values including the application configuration hashvalue, wherein the application configuration hash values are mapped toassociated configuration files; accessing, over the network, adevice-to-configuration library that stores a reference to the globalconfiguration library for each configuration file on a device; andascertaining, based on the access to the global configuration libraryand the device-to-configuration library, the application configurationhash value associated with the device for which the device configurationhash value is ascertained.
 16. A non-transitory computer readable mediumhaving stored thereon machine readable instructions, the machinereadable instructions, when executed, cause at least one hardwareprocessor to: ascertain, over a network, a device configuration statusof a device of a plurality of devices, and a device configuration hashvalue associated with a configuration file for the device; determinewhether the device configuration hash value matches an applicationconfiguration hash value; modify, based on a determination that thedevice configuration hash value matches the application configurationhash value, an application configuration status for the device tocorrespond to the device configuration status of the device; determine,based on a determination that the device configuration hash value doesnot match the application configuration hash value, whether the devicehas permission to locally modify the configuration for the device; andbased on a determination that the device does not have permission tolocally modify the configuration for the device, send, over the network,a configuration file to the device to modify, based on the sentconfiguration file, the configuration for the device, determine whetherthe sent configuration file is of a same file type present in a commandqueue for the device, and based on a determination that the sentconfiguration file is of the same file type present in the command queuefor the device, determine a command status of a command associated withthe sent configuration file, and implement, based on the determinedcommand status, a retry operation with respect to the command queue forthe device for the sent configuration file.
 17. The non-transitorycomputer readable medium according to claim 16, wherein the machinereadable instructions when executed by the at least one hardwareprocessor further cause the at least one hardware processor to: based ona determination that the device has permission to locally modify theconfiguration for the device, request, over the network, theconfiguration file that is associated with the device configuration hashvalue and is used by the device to modify the configuration for thedevice, and update, upon receipt, over the network, of the requestedconfiguration file, a configuration record associated with the devicebased on the requested configuration file.
 18. The non-transitorycomputer readable medium according to claim 16, wherein the machinereadable instructions when executed by the at least one hardwareprocessor further cause the at least one hardware processor to:ascertain, over the network, a request to update the configuration forthe device; ascertain, over the network, another device configurationhash value associated with the request to update the configuration forthe device; retrieve, over the network, a configuration file associatedwith the another device configuration hash value; and send, to thedevice and over the network, the retrieved configuration file associatedwith the another device configuration hash value to update theconfiguration for the device.
 19. The non-transitory computer readablemedium according to claim 18, wherein the machine readable instructionswhen executed by the at least one hardware processor further cause theat least one hardware processor to: notify, over the network, an entityassociated with the request to update the configuration for the device,the device configuration status of the device upon completion of theupdate, based on the retrieved configuration file associated with theanother device configuration hash value, of the configuration for thedevice.
 20. The non-transitory computer readable medium according toclaim 16, wherein the machine readable instructions when executed by theat least one hardware processor further cause the at least one hardwareprocessor to: receive, over the network, a request from an entity forthe configuration file that is used by the device; determine, based onthe received request from the entity for the configuration file that isused by the device, whether the configuration file that is used by thedevice is known or unknown; and based on a determination that theconfiguration file that is used by the device is known, generate, forthe entity, a response that includes an indication of the configurationfile that is used by the device.